No 'Makefile.PL' found - attempting to generate one

Eric Wilhelm on 2007-07-17T06:29:50

I do really appreciate the efforts of the cpan-testers, but some of the bare-metal smoke testing seems somewhat misdirected, especially regarding the handling of Module::Build distributions. Here's just one instance.

http://cpantesters.perl.org/show/Module-Finder.html

Every single Fail report on v0.1.4 is due to "No 'Makefile.PL' found - attempting to generate one".

I would prefer to *not* include Makefile.PL at all because there is another configuration scheme which says "prefer Makefile.PL over Build.PL?" (And of course it defaults to the wrong answer.)

So, v0.1.5 is going to include an "educational" Makefile.PL which starts with die. I know I can't educate everyone (or so they tell me), but at least I can make doing the wrong thing hurt.

---

Actually...

kane on 2007-07-17T09:09:35

Actually, every fail report is due to:

[ERROR] [Mon Jul 16 19:12:23 2007] This module requires 'Module::Build' and 'CPANPLUS::Dist::Build' to be installed, but you don't have it! Will fall back to 'CPANPLUS::Dist::MM', but might not be able to install!

The clue is in the [ERROR] tag...

You will keep running into issues like these until either all machines have Module::Build support, or the config_requires: extension to META.yml is accepted, implemented and supported in all deployed versions of CPAN.pm/CPANPLUS.

The traditional approach has been to at least use Module::Build's compat() feature to generate a Makefile.PL.

In this case, the tools do as best they can, and fail for obvious reasons.

That should be NA, right?

ferreira on 2007-07-17T18:43:25

When CPANPLUS says:

[ERROR] [Mon Jul 16 19:12:23 2007] This module requires 'Module::Build' and 'CPANPLUS::Dist::Build' to be installed, but you don't have it! Will fall back to 'CPANPLUS::Dist::MM', but might not be able to install!

and then

No 'Makefile.PL' found - attempting to generate one

it is trying to be helpful. But the smoker module (be it CPAN::YACSmoke, CPAN::Reporter or whatever) should recognize this case as NA and not FAIL. Would it be hard to tell this case apart?

On another note, Bundle::CPANPLUS should be augmented to include CPANPLUS::Dist::Build among the required modules. That's urgent if we expect Module::Build to be as omnipresent as ExtUtils::MakeMaker. (I may be wrong here, but at a glance I didn't find CPANPLUS::Dist::Build among the bundle modules.)

Yet another note: maybe our top smoker (BinGOs) could install that missing part of the toolchain in his smoking machines and spare us, poor module writers, from conceding and generating a traditional Makefile.PL in the name of compatibility.

Re:That should be NA, right?

Corion on 2007-07-17T19:33:47

generating a traditional Makefile.PL in the name of compatibility.

Isn't that more courtesy towards the user than some old ritual one has to follow? I'm constantly amazed by such ideas as Module::Build::Convert, which tries to automate a process for which there is absolutely no need - if it works with a Makefile.PL why move to Build.PL at all.

Courtesy vs Modernization

ferreira on 2007-07-17T20:26:17

Isn't that more courtesy towards the user than some old ritual one has to follow?

Yes. But we want to encourage users to move to brand new updated tools, don't we? Using only Build.PL makes sense if (1) that is supposed to work only for newer Perls and installations, or (2) you don't care if your module does not work unless people have up-to-date toolchains.

Re:That should be NA, right?

Aristotle on 2007-07-18T13:58:22

a process for which there is absolutely no need

That depends on whether you consider EU::MM fundamentally broken or not.

Re:That should be NA, right?

barbie on 2007-07-21T12:03:49

Would it be hard to tell this case apart?

Actually yes it is. This part of the configuration is not captured well in EU::MM and M::B and as a consequence CPAN.pm and CPANPLUS have to jump through hoops to get at it. Last time I checked EU::MM handles this better.

recognize this case as NA and not FAIL.

NA has a specific meaning, in that the module does not work on that perl/platform. This isn't the case in this situation, so should be a FAIL as the author is not providing support for the current standard toolchain. If they choose to insist on M::B then at the moment that will break because M::B isn't part of the current standard toolchain. In 5.10 M::B will be in core, so it can then be considered part of the standard toolchain. Assuming your user base will have exactly what you have on your machine is why you get FAIL reports.

CPAN Testers won't be hurt

brian_d_foy on 2007-07-17T13:40:38

Wouldn't a Makefile.PL with jsut a die just hurt the average Joe who falls for the trap because he sees a Makefile.PL? The CPAN testing won't really care and will just keep sending you FAIL reports.

It's your own fault

Alias on 2007-07-18T04:56:59

These failures are legitimate failures, and should remain.

When you choose your build system, as when you choose ANY dependency, you get its errors and baggage along with its good points.

Module::Build has an unresolved circular dependency on itself.

Unlike EVERY other module on CPAN, it says that the rules do not apply to it and that instead of working within the rules, EVERY end user should magically (via the "universal education" clause) know to install it BEFORE they start installing anything else.

This means that Module::Build doesn't auto-install, and Module::Build doesn't auto-upgrade.

So in the general case, EVERY user needs to EXPLICITLY make sure they have upgraded Module::Build before EVERY attempt to install a module.

If Module::Build adds File::ShareDir support, it simply won't work for most people and will break, because that feature only exists in the newest version.

For some reason I need to keep explaining this to people, over and over again, because they seem to keep forgetting.

Of all the people that know this problem exists, you should know it better than most.

In CPAN terms, you may not be responsible for creating the fault in Module::Build, but you ARE responsible for making the choice to start using and continuing to use a package build system in which this fault it known to occur.

The errors you are seeing are entirely legitimate because they represent the real world situation of what happens when someone tries to install one of your modules.

The entire reason the configure_requires: features is being added is that the problem is now unrepairable and we need to take more drastic action in order to try and at least mitigate the damage.

If you want to stop receiving errors caused by your build system being incompatible with the way CPAN works, I suggest switching to a build system that IS compatible with the way CPAN works.

I hear ExtUtils::MakeMaker works quite nicely.

we learn from pain, we learn from history...

Eric Wilhelm on 2007-07-18T09:21:56

"Module::Build has an unresolved circular dependency on itself." isn't quite correct. Distributions that require Module::Build need Module::Build, but Module::Build will build just fine without anything but it's own tree.

Yes, that is a problem if the CPAN(PLUS) client can't know that it is fatally out-of-date. Everything is a problem if we have to expect an old tool (which could be easily updated) to do the right thing.

Requiring a particular *version* of M::B does need configure_requires. But the converse of this is that ExtUtils::MakeMaker cannot fix bugs or add features. It's all the same thing and we do need configure_requires to solve it.

But it really comes back to the tool. My die() message says "run the Build.PL file". Great for humans, bad for old rusty tools. I know that.

I'm not just being a whiny blowhard. I would really just like to raise the awareness. You know, so hopefully we don't go through this (and the cross-compiling thing (btw, can makemaker cross-compile?)) the hard way on Perl 6/parrot. And generally just to make people realize how relatively good the perl toolchain has been for quite a long time and how hard people have worked to make that happen.

Still, I await the day when we apply the final fix.

Re:we learn from pain, we learn from history...

diakopter on 2007-07-18T17:47:44

Still, I await the day when we apply the final fix.

There is another alternative to the problem/solution you suggest in that post. For every existing module pointed-to by those indices, set the URL (and checksums) of the distribution release to the location of a distribution release that upgrades the toolchain. Yes, there would be an uproar if preparations were not made by user education via public announcements and a months-ish waiting period, but it would achieve the desired effect. Mandatory upgrade ("if you're using old versions of our tools, so sorry, the indices they reference are deprecated. Broken things can't be supported forever").

Re:It’s your own fault

Aristotle on 2007-07-18T14:04:50

The entire reason the configure_requires: features is being added is that the problem is now unrepairable

“Now unrepairable”?! Yeah right! It was never a problem before, which is why CPAN::MakeMaker was never invented. Pffft.

The CPAN toolchain has always had this problem. Module::Build just put the tweezers on tight enough to force a fix.

Go on, shoot the messenger as much as you want. Won’t change anything about the reality of his message, but hey…

and we need to take more drastic action in order to try and at least mitigate the damage.

And good on Module::Build for making it happen! It was high time to the n-th power.

Re:It's your own fault

chromatic on 2007-07-21T19:19:57

I hear ExtUtils::MakeMaker works quite nicely.

... provided that, and I paraphrase your message elsewhere, "EVERY end user should magically (via the "universal education" clause) know to install [a working make utility] BEFORE they start installing anything else."